Typically, in service center or call center environments, such as sales, collections, customer service, etc., the different media involved in the transaction are completely independent. Consider, for example, just the different media of voice and data. If an incoming call from a customer is answered by a first agent, and that first agent discusses an item with a customer, and accesses a database to obtain information to service the customer, and then determines that the call should be handled by the second agent, then the first agent transfers the call to the second agent. However, only the voice portion of the call is typically transferred. Any data located and examined by the first agent, or received by the first agent, or input by the first agent, is not completely transferred to the second agent. The second agent must go through the process of locating and accessing various databases and applications to obtain the information necessary to service the calling party, even though those databases and/or applications were already located and accessed by the first agent. Even worse, preliminary information collected by the first agent, but not entered into a database, is temporary (transitory data) and may be destroyed when the first agent is disconnected from the customer, rather than being transferred to the second agent. Thus, agent effort is duplicated, agent time is wasted, agent efficiency is reduced, and service to the customer is delayed while the second agent obtains the same information previously obtained by the first agent. Further, the customer may become frustrated if the customer has to repeat the request or state the problem to the second agent, and again to a third agent if transferred again, etc.
One approach to this problem is, once the first agent obtains information, such as by downloading from a database, that information is transferred to the terminal of the second agent when the voice call is transferred from the first agent to the second agent. The amount of information obtained from the database may be quite large and require several seconds to transfer, thus wasting time and system resources, such as by occupying the network for the duration of a file transfer from a database. Also, the agent terminals may not be identical and the terminal of the second agent may not be able to accept all of the information from the terminal of the first agent. In addition, the needed information may be in the first database previously accessed and then closed by the first agent, but not in the second database accessed by the first agent, in which case the file or information transferred from the second database would be unnecessary and a waste of system resources.
Many transactions require more than one step or contact. For example, consider the following scenario relating to the processing of a claim or report arising from an automobile accident. The customer (a calling party) calls the general telephone number for the business (an insurance company). A first agent (a receptionist) or an interactive voice response (IVR) unit answers the call to determine how the call should be routed (new claims, status of existing claims, general information, new insurance applications, employment information, etc.). The customer advises that the customer wishes to report an accident and place a claim. The customer is then transferred to a second agent (a claims reporter). The claims reporter obtains the information from the customer as to the accident and the damage. The claims reporter then assigns a third agent (a claims adjuster) to appraise the automobiles involved, inspect the damage, and assign a value to the claim. The claims adjuster then enters a report regarding the accident, the damage, and the value. The claims adjuster, or possibly another (fourth) agent, then calls the customer or sends correspondence to the customer to report the results of the inspection. If the customer disagrees, then the case may be sent to a higher level (fifth) agent for review and further evaluation or discussion with the customer. A letter may then be sent to the customer regarding the evaluation of the claim. The insurance company may or may not have an automatic follow-up call or letter by another (sixth) agent if the customer does not respond in a predetermined time. Finally, when agreement is reached with the customer, another (seventh) agent in disbursements may issue a check to the customer, thus finally concluding the case.
Note that this single transaction, processing a claim, has numerous steps and involves numerous agents. Further, at any point, the information available to any agent may be incomplete or inadequate if, for example, the physical file is in the office of another agent. Even if there are sufficient databases to contain all of the needed information, the agent attempting to perform a task may have to expend substantial time and effort to locate and search the various databases to find the necessary information. Thus, even when the customer is talking with an agent who was previously working on the case, there may be a delay while the agent searches for the right database containing the needed information.
The dilemma faced by any business using diverse information sources and infrastructures, such as offices in multiple locations as New York, Los Angeles, Denver and Atlanta, is the near autonomy of the information pertaining to the various discrete transactions that make up a business process or function. Autonomy is used in the sense that the transactions are frequently serviced using different independent applications (computer programs), such as an inventory system application, a help desk application, a contract management application, an accounts receivable program, a sales order entry, etc. Even transactions which use the same application frequently exist independently as stored documents on file servers, or as records in various department-specific databases. Further, the databases and file servers may be in different locations.
Client/server architecture provides for using applications on desktop personal computers (PC) to combine process or transaction related information. However, the correlation of related information fragments is typically based on single transaction processing. In other words, the correlation between information elements is very application specific. The relationship between the information elements has to be reconstructed for every instance of a transaction, even when a transaction is simply being transferred from one application to another application within the same system as part of a business process. Maintaining continuity between independent systems is even more problematic.
One problem with the prior art is that the prior art treats each event, such as a call, a contact, a mailing or a step, as an independent event, even when an event is merely one of a plurality of events necessary to complete a transaction, such as completing a task or producing a desired result.
Another problem with the prior art is that, when a call is transferred from a first agent to a second agent, a typical prior art system requires the second agent to duplicate the effort of the first agent by locating most of the information that the first agent had previously located.
In another version of the prior art, the problem is that the prior art transfers complete database records, which may contain excessive amounts of data, especially for the process involved.
Further, the prior art does not provide for the preservation or the automatic reconstruction of the connections and associated resources necessary to further a contact. That is, the record of any such connections and associated resources used during a communication is destroyed once the communication has been completed. Thus, the time and agent effort necessary to identify and re-establish such connections is wasted.
In addition, the prior art does not provide for automatically identifying the resources necessary to conduct and support a communication and reserving those resources for a future communication.